入职一年多的一些思考
文末福利：淘系前端团队 618 实践小册
我们所有的知识都开始于感性，然后进入到知性，最后以理性告终。--康德
从入职到现在已经一年半多的时间，想通过这篇文章回顾一下个人过去在阿里的轨迹，并总结一些这一年多以来的思考和收获。成长的路径是相似的，希望能够抛砖引玉给初出入阿里的新人一些参考。
阅前声明：每个人的经历、视角、以及所处的环境都会有所差异，这是一篇非常主观的总结，观点可能会有所片面，如有不同意见欢迎评论交流~
NO.1
初心
或许内心还是一个不太“安分”的人，原本毕业后已经在家乡过上了父母期望的生活。但对于未来的过于确定反而让我有一种隐隐的不安，眼看当前甚至未来的生活将变成来回的机械运动在舒适区打转，便想要寻求一些变化。最终来了阿里，初衷是希望进一步的开拓视野，在感受大厂工作模式的同时，能让自己有所成长。
NO.2
大型互联网公司的运转模式
1、KPI导向。进入公司后的第一个感受是周围的同学都非常用活力，都具备较强的主管能动，没有丝毫的倦怠，对于一家十几万人的公司来说觉得不可思议。这得益于KPI机制，在制定KPI的时候能明显感受到一个自上而下拆解命题的过程，从公司最顶层的战略逐层的进行向下拆分，通过不停的对焦，细化为每个人的财年目标。因此以财年为单位，每个人都要为自己的目标负责，自然需要持续的保持专注。
没有KPI，谈价值观都是空话。--马云
头条大部分的商业决策，在公司成立两个月内都做的差不多了。--张一鸣
2、价值观保证。价值观是基础的行为准则，是一个公司的灵魂以及对员工的期望。只有所有人都认可同一个价值标准，才能从个人到团队一起把事情做好并保持战斗力。
3、企业文化。组织的进步是阶梯式的，需要一批有一批的人一起推进。因此文化或资料需要一种媒介从前到后的不断传承，ATA、阿里味儿等论坛一起打造了一个良好的内部氛围。
以上三点，我认为是想要做一个好的企业不可或缺的三个要素。
NO.3
晋升带来的思考
近期参与了晋升，结果尚不得而知，但从中还是发现了很多自身的不足并为日后带来了一些新的思路。晋升的过程本质上是对过去的梳理总结以及对未来的思考展望，就像照镜子一样自我审视。在总结过程中需要还原过去的思考问题解决问题的过程，期间往往能发现很多过去的未曾想到的问题，会让人意识到在当初的某个节点应该做某件事但是却做的不够到位，这也是促进成长的地方。另一方面也是一个评委帮忙review的过程，有时候自己的想法未必全面，review期间能够通过评委的提问意识到更多问题，让人进一步思考自身的定位以及方向。在此对于发现的问题和思考做以下几点总结：
1、关于述职
述职不仅仅是对过去所做事情结果的罗列，更多的是要讲清楚前因后果以及做事思路，过程和结果一样重要。整体述职思路应该是：当初为什么这么做（价值在哪、有没有横向对比、有没有数据支撑）、怎么做（实现思路是什么，怎么推动的）、最后才是结果。这整个思路也应该是平时做事时就形成基本逻辑，做的时候就应该有体感，不应该等到最终才开始去想。
2、业务上的思考
目前对于业务有一定的数据体感以及整体的业务策略认知，但基于业务目标带来的技术侧的思考深度还有所欠缺。后续的思考方式可以做下调整：从整体业务大的目标出发，理解基于这个目标的业务具体策略，结合整理的面以及具体的点，从点到面，定义清楚问题，然后在技术侧做整体的规划、能力拆分来实现业务的诉求，同时面向未来做技术侧的沉淀。
3、推导思维
对于方案选择要有整体的横向调研，以及数据的充分对比以及求证。对于现存方案追溯其形成的历史，知其所以然。举个例子：接手某个业务的技术栈使用的是小程序，可以去思考为什么要用小程序？有没有什么更好的方案？选择这个方案时是否经过严谨的分析和对比。
4、思路结构化沉淀
对于一些评委问到的问题，比如未来技术上的规划，虽然知道，但回答的不是很好有些甚至没有说上来。一方面有紧张的因素在，但本质上的因为没有对知道的东西进行结构化的梳理，对于多个点之间的关联还没有去深挖。因此对于一些平时的想法，要即时进行记录并结构化的梳理，尽量从高的维度对应到要做的大盘中。避免有想法但被问的时候无法迅速的对应以及系统化的输出。做ppt的过程本质上其实就是一个结构化的过程，不管是前期做规划还是里程碑的整理。现在养成了一个习惯，将想法通过ppt记录下来，定期进行结构化的梳理，有时会提炼出很多想法。
5、分享状态
这其实是一个熟练度的问题。述职时思路还算清晰，但姿态表现一般，整体分享的时候应该保持好一个强自信的状态，日常工作中需要多加练习。
NO.4
做事的底层逻辑
基于过去的一些经历，抽象出了一套做事的底层逻辑。我认为这套逻辑不光是在工作中，在生活中也可以大大收益。
解题性思维
过去的我，聚焦于解决问题，这也是传统应试教育交给我们的模式：给你一张试卷，试卷上有几个确定的题目，你所要做的是针对这些题去寻求解法。整个过程可以抽象为下面这张图：
其实很多人的工作模式都是如此，对于一个已知的问题去求解，问题解决后又进入下一个问题。这样看似很好的完成了工作，但其实只能算是一个很好的执行者。很容易进入一种怪圈，会让人感觉到仿佛一直在进行重复劳动，做的事情容易杂乱不成体系。包括我在内的很多技术同学，很容易陷入技术的旋涡中，专注写代码的同时，忽略了思考为何要这么做。这是解题性思维。
结构化思维
更好的做法应该是结构化的思考和做事。
1、推导过程
在刚开始做一件事情的时候可以采用3W1H原则（WHAT、WHY、WHO、HOW），即：这件事是什么？为什么要做这件事？应该谁来做最合适？如何做？
凡是都有因果关系，多问自己一些问题，可以更加结构化的来看待一件事情，也能更好的帮助自己梳理清楚做某件事的价值。
以淘小铺为例，基于3W1H可以提出一系列的问题：这个业务是做什么的（WHAT）、业务的目标是什么（WHAT）、价值何在（WHT）、为什么要用小程序方案（WHY）、为什么我来做（WHO）、业务要怎么落地（HOW）、如何帮助业务实现业务目标（HOW）……
2、定义问题
一个问题如果被定义出来了，那就已经解决了一半。
定义问题其实比解决问题更重要，小到个体，大到一家公司，甚至一个国家。
国家定义的问题：实现全面建成小康社会。
阿里定义的问题：让天下没有难做的生意。
PDD定义的问题：建立消费者到工厂可信任的交付机制。
其实最根本逻辑还是定义问题、拆解问题到最后解决问题的循环过程。不妨拓宽一下认知的边界，尝试自己定义当前问题。基于下面这个模型不停地迭代，组织和个人才能不断进步。
最后回归到个人，在工作中也要不断的去思考定义和解决当下的问题。我觉得主要两个方面去思考：
自上而下，要理解业务的目标是什么。基于下一年甚至更长期的业务目标，去思考技术上能做的事情。这样可以避免杂乱的做事，有利于加深对所做业务的理解和判断。
自下而上，要结构化的整理工作中遇到的问题。通过向上建树，抽象出本质问题，提供根本性的解决方案。
还是以淘小铺这个业务为例：
自上而下分析目标：21财年的目标做到日均 xxx 万 GMV。
推导过程：基于这个目标业务上有很多决策，如：要做淘内自购、勋章激励、人群细分运营、店铺自运营等等。而技术侧要考虑的时候如何帮助业务达到这个目标，即业务赋能，核心是要帮助业务快速的试错与决策，因此可以建设abtest的能力。
眼下或许需要高优先级去完成业务支撑的问题，但后续更多要做的是了解需求背后的根本问题提供根本上的解决方案。
自下而上抽象问题
比如当前代码质量一般，以此为中心，自然是想到定制代码检查、推动code review等来解决。但在往上建树分析，会发现代码质量问题本质是解决研发效率以及维护成本的问题。因此已研发效率为中心进行思考，又会发现更多可以做的事情，如：物料库沉淀、开发流程优化等等。
回复 “618” 有福利
欢迎关注东半球最大的前端团队
喜欢就点这里